The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: youknowriad <[email protected]>
Co-authored-by: ellatrix <[email protected]>
Co-authored-by: ntsekouras <[email protected]>
Co-authored-by: jeryj <[email protected]>
Co-authored-by: getdave <[email protected]>
Co-authored-by: draganescu <[email protected]>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

Size Change: -284 B (-0.02%)

Total Size: 1.77 MB

_{compressed-size-action}

Flaky tests detected in 82a5f29.
Some tests passed with failed attempts. The failures may not be related to this commit but are still reported for visibility. See the documentation for more information.

🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/11370202153
📝 Reported issues:

• [Flaky Test] Navigates the items list via UP/DOWN arrow keys #64334 in /test/e2e/specs/site-editor/dataviews-list-layout-keyboard.spec.js

This seems logical for the Gutenberg Plugin but not necessarily the WP 6.7 release.

As you know we decoupled "zoom out affordances" from "zooming level" in order to set us up for what you're proposing here (essentially deprecating zoom-out as a mode, leaving us with just edit and navigation).

However, in 6.7 everything has proceeded along the lines that zoom-out will remain a mode so I'm relunctant to change that in the 6.7 branch as this stage (Release Candidate) for fear of introducing more issues.

For me, trunk and wp/6.7 implementations of Zoom Out are now mutually incompatible and thus we will need to target all future Zoom Out fixes for 6.7 directly into the wp/6.7 branch. Those fixes might need to be "backported" to trunk but that will be on a case by case basis.

I'd like to get some input from @kevin940726 for his opinion on this approach.

Are we sure we'll not have a different selection model when zooming out? Is the discussion set on using edit mode when zoomed out at all times? If we remove the mode but sitll end up with a different selection model what strategy will we employ?

@getdave and I worked together to decouple the mode change affecting the selection model from the scale factor. So I do see how this PR simplifies things. But I don't see design weighing in around how should this UX work, and we keep developing in engineering iterations. My fear is we'll then come back once there is some UX clarity.

@getdave I'll let you make the right decision for 6.7 but for me, if there's zoom-level state in 6.7, I don't see why we should be keeping two states for the same thing. you might consider that it's a big change for 6.7 and that would be fine by me though.

@draganescu The current PR actually keeps the distinct interaction model for zoom-out (the unification is in the other PR), The important bit for me is that currently in trunk zoomLevel and zoom-out mode for the same thing, there's no flow where we want them to be disconnected, so there's no need to keep two states.

The important bit for me is that currently in trunk zoomLevel and zoom-out mode for the same thing, there's no flow where we want them to be disconnected, so there's no need to keep two states.

In the site editor, there's the Styles > Browse Styles where zoomed level is engaged, but I'm not sure if the section block selection behavior should be active. Maybe @richtabor or @jasmussen can provide some input.

In the site editor, there's the Styles > Browse Styles where zoomed level is engaged, but I'm not sure if the section block selection behavior should be active.

Doesn't seem worth keeping the two, just for browse styles. So even tradeoffs as a result of merging, seem fine.

I see the zoom level and UI changes as different things. There's the existing scenario for 'Browse Styles' that I don't think should change the UI. And in the future for image cropping full-width images, it would be nice to zoom out to more easily position the crop in context. I'm sure there are other scenarios where keeping them separate would be useful.

I think given the level of uncertainty around whether this is the right approach we should stick with stability in 6.7. Therefore let's not backport this one.

What do you think @draganescu @ajlende? Can we move forward like that?

I think given the level of uncertainty around whether this is the right approach we should stick with stability in 6.7. Therefore let's not backport this one.

Yeah, let's hold off on moving this to 6.7 unless it's fixing a bug in that branch.